Global Enumerations

SystemAdmin - Tue Feb 24 16:52:58 EST 2009
Hi Louie,

I"m sorry I just reread your post, and you might of solved my problem I just didn't understand it.

I have to look up the command AttrType modify that you are referring to. I just haven't worked with it before and don't fully understand the syntax that you use to program it.

Thanks again

Jamie

llandale - Wed Feb 25 14:04:04 EST 2009
Ok, let me step back a bit.

All attributes definitions must have an attribute 'type' which restricts ..err.. clarifies what kinds of information can be in that attribute. Attr 'Count' is of type 'Integer'; attr '%Complete' is of type 'Real' (with boundaries 0.0 - 100.0); 'Name' is of type 'string' and 'Object Text' is type 'Text'. In the case of '%Complete' you would create a type called 'Percent' of base type 'Real' with min and max values of 0.0 and 100.0, and THEN create Attr Def '%Complete' that uses type 'Percent'.

An 'enumerated' attribute is one that has a specific list of legal values, or of course null. You cannot assign a value to an object for that attribute that's not in the list. A 'single' enumerated attribute allows you to pick zero or one of the values; e.g. 'Priority' can be 'High' or 'Medium' but not both. A 'multi' enumerated attribute allows you to pick zero or more of the values, e.g. 'ChoresToDo' can be both 'MakeBed' and 'CleanRoom'.

For enumerated attributes, the legal values are defined in the 'Type' and you must create your own 'Type' before creating the actual attribute. For example, type 'Boolean' is really an enumerated type of legal values 'False' or 'True' allowing you to create attr definition 'Verified'. You can create a single enumerated Type perhaps 'Importance' with enumerations 'Critical', 'High', 'Medium', 'Low', and 'Trivial', and then create several Attr Defs that use them, perhaps 'Implementation Priority' and 'Customer Demands', assigning values for each object. However, most of the time you create an enumerated type for use by a single enumerated definition. They can have the exact same name, perhaps definition 'Available Upgrades' can be based on type 'Available Upgrades'.

You cannot change the type of an attribute; if 'Name' is type 'String' you cannot change it to type 'Text'. The awkward way to do that is this for each object copy 'Name' to 'Temp' Rename 'Temp' to 'Name'.

Back to the thread. You CAN change the enumerated list of an enumerated type; lets do that with the GUI.

If you change the ORDER in which the values are displayed, then for multi-enumerated the order displays the new order for each object, if you update the object. If you change enumerated A-B-C to C-A-B and an object starts with values A and C, the object will still say A C even after you re-order it; you can force redisplay (and reordering) in DXL with <obj.NameAttr = obj.NameAttr> for all objects in the entire module; in this case C A.

If you change the spelling of an enumerated, perhaps 'C' to 'CC', then all objects (oddly) immediately update to the new value.

If you delete an enumerated, all objects lose that value immediately.

Not sure what happens if you have rights to modify the Type like this but don't have rights to modify the Attr Values.

Now lets modify a Type with DXL.

The 'modify' command lets you define the new order, and the undocumented version including the mapping[] array lets you associate old values with new, where -1 means no association. IIRC if mapping[0] has the value 2 it means that the new enumerated value in the other arrays in position 0 maps directly to the older enumerations at position 2. In that case, it lets you move 2 to 0 (if spelled the same) and also lets you change the spelling of the old 2 into the new 0.

I don't think its reasonable ..err.. possible to expect a generic DXL script to read the old list of enumerations (from an actual module), read the new list (from the template), and be able to figure out how to populate the arrays, including the mapping, needed for the 'modify' command. If you renamed 2 and moved it to position 0, how on earth would the script know that? e.g. A B C is old and CC A B is new, that could be 3 straight renames, that could be renaming C to CC and moving it to the top (the 2-to-0 example above), and it could also be deleting C and inserting a new CC at the top.

No, I'm sure your rename enumerations script will need to be tailored to change the enumerations of each specific attribute. Perhaps you can write one that reads an CSV file with the info you want, but you'd still need a CSV file for each and every rename you attempt.

• Louie

llandale - Tue Feb 24 16:34:27 EST 2009
I'm sure the GUI has no solution, but you can write DXL to do it. For enumerations it would get pretty sticky.

There is an undocumented perm AttrType modify(AttrType, string, string], int[, int], int[, string&) which has one more 'int[]' parameter than in the manual, that lets you map new enumerations to the old.

If the old Enumerations were A/B/C and the new are A/C/B/D, you might intend ...

[] ... to swap the display order of B and C, and add D.

[] ... to rename all existing C to B and rename all existing B to C and then add D; the new mapping function above will let you do that. Perhaps A/X/Y/D would be easier to understand.

[] ... move C, map existing B to D, create new B. Other possibilities exist.

Also, when you map the object's haven't actually changed values yet and will generally display the OLD values; which means pretty much you need to plow through all the objects and do this: obj.NameAttr = obj.NameAttr, in order to update the display.

So no, you cannot just modify the enumerations and push it out, you'd have to mindfully decide what you intend and customize the DXL to do it for you.

Good luck.

• Louie